Document Application Integration credential access - #382

Summary

• document the exact-permission integrations.authConfigs.get credential-disclosure path and its Critical classification
• document the exact-permission integrations.integrations.invoke stored-credential workflow path and its conditional High classification
• document the tested connectors.connections.create unauthorized runtime identity attachment path, including its cross-project prerequisite and limitations
• explain Gmail, Drive, Workspace, HTTP connector, and cross-project service-account scope boundaries without claiming arbitrary-user, arbitrary-project, or domain-wide access
• add known-resource, source/Terraform/log, Cloud Asset, and read-only IAM fallbacks for principals without list permissions
• make explicit that GCPPEASS only checks IAM and never retrieves an auth profile or invokes a workflow

Live validation

All three paths were independently tested on 2026-09-08 using authorized disposable GCP lab resources.

For integrations.authConfigs.get, a custom role contained only that permission. Before binding, profile GET and LIST returned 403. After binding, GET returned 200 with the exact synthetic bearer token while LIST remained 403, and project testIamPermissions returned only the get permission from the candidate set.

For integrations.integrations.invoke, project testIamPermissions returned only the invoke permission from the candidate set. Integration list/version GET, Secret Manager access, direct connector action execution, service-account actAs, and token minting remained denied. The principal still invoked a deliberately published workflow; a controlled endpoint confirmed that its synthetic API key was attached without logging or returning the key.

For connectors.connections.create, the creator had exactly that permission in attacker project A and zero tested permissions in victim project B, including no iam.serviceAccounts.actAs or token permissions on B's runtime service account. B had previously delegated token minting on that disposable runtime account to A's Google-managed Connector service agent. The A connection became ACTIVE with the B runtime identity and secret reference. A separate invoke-only identity with no B permissions executed it, and the controlled B receiver returned credential_match=true. This does not establish arbitrary-project access: the explicit B-to-A Connector service-agent trust and an execution path are prerequisites. The no-service-agent-trust LRO was inconclusive and is identified as such.

No real Workspace credential or data was used. Every created auth profile, connection, integration, IAM binding, custom role, service account, secret, Cloud Run resource, image, source artifact, service-agent grant, source repository, and temporary API enable was removed. Final audits found zero test resources and restored the APIs to their prior disabled state.